System and method to generate risk relationship package using a flexible structure framework

ABSTRACT

A risk relationship package data store may contain electronic records, each electronic record representing a risk relationship package between an enterprise and an entity, and including, for each package, an electronic record identifier and an overall attribute value. A computer server may transmit, to a remote device associated with the entity, a set of potential types of risk coverage based on information in an available type of risk coverage data store. The server may then receive an indication of a selected subset of the potential types of risk coverage and, based on the received indication and a pre-determined rule, generate a risk relationship package for the entity using a flexible structure framework. The server may calculate an overall attribute value for the package based on an attribute algorithm (such that at least one reduction to the overall attribute value is applied based on an amount associated with the selected subset).

CROSS REFERENCE TO RELATED APPLICATION

This is a continuation of U.S. patent application Ser. No. 17/118,488,entitled “SYSTEM AND METHOD TO GENERATE RISK RELATIONSHIP PACKAGE USINGA FLEXIBLE STRUCTURE FRAMEWORK,” filed Dec. 10, 2020, the entirecontents of which are incorporated herein by reference for all purposes.

TECHNICAL FIELD

The present application generally relates to computer systems and moreparticularly to computer systems that are adapted to accurately and/orautomatically generate a risk relationship package using a flexiblestructure framework for an enterprise.

BACKGROUND

An entity may enter into a risk relationship with a risk relationshipprovider (e.g., an enterprise or insurer) to protect itself from damagesassociated with unexpected occurrences. For example, the riskrelationship may provide payments associated with unforeseen accidents,weather events, power outages, etc. In some cases, an entity (e.g., ahomeowner) may purchase from an enterprise a “package” of protectionsassociated with different types of risk. Note, however, that packageprofitability and rate levels may be difficult for the enterprise toassess. Moreover, any package changes might require full rate, rule, andform filings and programming with a state Department Of Insurance(“DOI”) which can be quite costly and time consuming.

It would be desirable to provide systems and methods to automaticallyestablish a risk relationship package using a flexible structureframework in a way that provides fast and accurate results. Moreover,the package and flexible structure framework should be easy to access,understand, update, etc.

SUMMARY OF THE INVENTION

According to some embodiments, systems, methods, apparatus, computerprogram code and means are provided to automatically establish a riskrelationship package using a flexible structure framework in a way thatprovides fast and accurate results and that allows for flexibility andeffectiveness when creating those results.

In some embodiments, a risk relationship package data store may containelectronic records, each electronic record representing a riskrelationship package between an enterprise and an entity, and including,for each package, an electronic record identifier and an overallattribute value. A computer server may transmit, to a remote deviceassociated with the entity, a set of potential types of risk coveragebased on information in an available type of risk coverage data store.The computer server may then receive an indication of a selected subsetof the potential types of risk coverage and, based on the receivedindication and a pre-determined rule, generate a risk relationshippackage for the entity using a flexible structure framework. Thecomputer server may calculate an overall attribute value for the packagebased on an attribute algorithm (such that at least one reduction to theoverall attribute value is applied based on an amount associated withthe selected subset) and create a new electronic record in the riskrelationship package data store, including the calculated overallattribute value.

Some embodiments comprise: means for accessing, by the back-endapplication computer server, a risk relationship package data store thatcontains electronic records, each electronic record representing a riskrelationship package between an enterprise and an entity, and including,for each risk relationship package, an electronic record identifier andan overall attribute value; means for transmitting, from the back-endapplication computer server to a remote device associated with theentity, a set of potential types of risk coverage based on informationin an available type of risk coverage data store; means for receiving,from the remote device, an indication of a selected subset of thepotential types of risk coverage; based on the received indication and apre-determined rule, means for generating a risk relationship packagefor the entity using a flexible structure framework; means forcalculating an overall attribute value for the generated riskrelationship package based on an attribute algorithm such that at leastone reduction to the overall attribute value is applied based on anamount associated with the selected subset; and means for creating a newelectronic record in the risk relationship package data store, includingthe calculated overall attribute value.

In some embodiments, a communication device associated with a back-endapplication computer server exchanges information with remote devices inconnection with an interactive graphical user interface. The informationmay be exchanged, for example, via public and/or proprietarycommunication networks.

A technical effect of some embodiments of the invention is an improvedand computerized way to automatically generate a risk relationshippackage in a way that provides fast and accurate results. With these andother advantages and features that will become hereinafter apparent, amore complete understanding of the nature of the invention can beobtained by referring to the following detailed description and to thedrawings appended hereto.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram of a system in accordance with someembodiments.

FIG. 2 illustrates a method according to some embodiments of the presentinvention.

FIG. 3 is one possible homeowners insurance package evolution inaccordance with some embodiments.

FIG. 4 illustrates coverage compositions for homeowners insurancecoverage packages according to some embodiments.

FIG. 5 illustrates a flexible structure framework for variouspre-defined packages in accordance with some embodiments.

FIG. 6 illustrates another flexible structure framework for coveragepackages according to some embodiments.

FIG. 7 illustrates package coverage foundation endorsements inaccordance with some embodiments.

FIG. 8 shows some structure options according to some embodiments.

FIG. 9 is a structure design in accordance with some embodiments.

FIG. 10 illustrates a version and filing approach according to someembodiments.

FIG. 11 shows coverage configuration versions in accordance with someembodiments.

FIG. 12 is a filing approach for coverage packages according to someembodiments.

FIG. 13 is a package creation method in accordance with someembodiments.

FIG. 14 is method associated with protection tiers or levels accordingto some embodiments.

FIG. 15 is a more detailed block diagram of a system according to someembodiments.

FIG. 16 illustrates a question display that may be used to coderespondents into preliminary persona categories in accordance with someembodiments.

FIG. 17 is a block diagram of an apparatus in accordance with someembodiments of the present invention.

FIG. 18 is a portion of a tabular risk relationship package databaseaccording to some embodiments.

FIG. 19 illustrates a tablet computer displaying an insurance packagedisplay according to some embodiments.

DETAILED DESCRIPTION

Before the various exemplary embodiments are described in furtherdetail, it is to be understood that the present invention is not limitedto the particular embodiments described. It is also to be understoodthat the terminology used herein is for the purpose of describingparticular embodiments only and is not intended to limit the scope ofthe claims of the present invention.

In the drawings, like reference numerals refer to like features of thesystems and methods of the present invention. Accordingly, althoughcertain descriptions may refer only to certain figures and referencenumerals, it should be understood that such descriptions might beequally applicable to like reference numerals in other figures.

The present invention provides significant technical improvements tofacilitate the generation of risk relationship packages using a flexiblestructure framework. The present invention is directed to more thanmerely a computer implementation of a routine or conventional activitypreviously known in the industry as it provides a specific advancementin the area of electronic record analysis by providing improvements indata leveraging to generate risk relationship packages using a flexiblestructure framework. The present invention provides improvement beyond amere generic computer implementation as it involves the novel orderedcombination of system elements and processes to provide improvements indata leveraging to generate the package, calculate an overall attributevalue, etc. Some embodiments of the present invention are directed to asystem adapted to automatically analyze insurance data, aggregate datafrom multiple sources, automatically identify personas, automaticallyidentify how these personas drive selections, and/or automaticallygenerate risk relationship packages. Moreover, communication links andmessages may be automatically established, aggregated, formatted, etc.to improve network performance and/or bandwidth based on the package anda flexible structure framework (e.g., to streamline a workflowassociated with a package). Moreover, the maintenance of the computersystems, databases, etc. may be simplified as a result of embodimentsdescribed herein.

Embodiments may provide a flexible structure framework and an activemonitoring approach to let an enterprise more effectively leveragepackage options and improve business results. FIG. 1 is a high-levelblock diagram of a system 100 according to some embodiments of thepresent invention. In particular, the system 100 includes a back-endapplication computer server 150 that may access information in a riskrelationship package data store 110 (e.g., storing a set of electronicrecords that represent risk associations, each record including, forexample, one or more risk relationship package identifiers, an overallattribute value, etc.). The back-end application computer server 150 mayalso retrieve information from other data stores or sources, such as anavailable type of risk coverage data store 120, in connection with arisk relationship platform and flexible structure framework 155 to view,analyze, and/or update the electronic records. The back-end applicationcomputer server 150 may also exchange information with a first remoteuser device 160 and a second remote user device 170 (e.g., via afirewall 165). According to some embodiments, an interactive graphicaluser interface platform of the back-end application computer server 150(and, in some cases, third-party data) may facilitate forecasts,decisions, predictions, and/or the display of results via one or moreremote administrator computers (e.g., to gather additional informationabout an existing risk relationship package) and/or the remote userdevices 160, 170. For example, the first remote user device 160 maytransmit annotated and/or updated information to the back-endapplication computer server 150. Based on the updated information, theback-end application computer server 150 may adjust data in the riskrelationship package data store 110 and the change may be viewable via ageneric second remote user device 170. Note that the back-endapplication computer server 150 and/or any of the other devices andmethods described herein might be associated with a third-party, such asa vendor that performs a service for an enterprise.

The back-end application computer server 150 and/or the other elementsof the system 100 might be, for example, associated with a PersonalComputer (“PC”), laptop computer, smartphone, an enterprise server, aserver farm, and/or a database or similar storage devices. According tosome embodiments, an “automated” back-end application computer server150 (and/or other elements of the system 100) may facilitate theautomated access and/or update of electronic records in the riskrelationship package data store 110. As used herein, the term“automated” may refer to, for example, actions that can be performedwith little (or no) intervention by a human.

As used herein, devices, including those associated with the back-endapplication computer server 150 and any other device described herein,may exchange information via any communication network which may be oneor more of a Local Area Network (“LAN”), a Metropolitan Area Network(“MAN”), a Wide Area Network (“WAN”), a proprietary network, a PublicSwitched Telephone Network (“PSTN”), a Wireless Application Protocol(“WAP”) network, a Bluetooth network, a wireless LAN network, and/or anInternet Protocol (“IP”) network such as the Internet, an intranet, oran extranet. Note that any devices described herein may communicate viaone or more such communication networks.

The back-end application computer server 150 may store information intoand/or retrieve information from the risk relationship package datastore 110 and/or available type of risk coverage data store 120. Thedata stores 110, 120 may be locally stored or reside remote from theback-end application computer server 150. As will be described furtherbelow, the risk relationship package data store 110 may be used by theback-end application computer server 150 in connection with aninteractive user interface to access and update electronic records.Although a single back-end application computer server 150 is shown inFIG. 1 , any number of such devices may be included. Moreover, variousdevices described herein might be combined according to embodiments ofthe present invention. For example, in some embodiments, the back-endapplication computer server 150 and risk relationship package data store110 might be co-located and/or may comprise a single apparatus.

In some embodiments, the system 100 may be adapted over time to optimizetake rates, targeting various consumer segments. Moreover, packageprofitability may be managed at the coverage level and package coveragecomposition changes may require little or no DOI filings. With aflexible structure bundling individual optional coverages, ratings maybe done at individual optional coverage level and package discountlevels may vary by optional coverages.

Some embodiments may be associated with fewer coverages and certainpopular coverages might be included in all packages. As the number ofcoverages increase, the limits may largely stay the same. Aconsumer-centric design (as opposed to one centered on an insuranceprovider) might, for example, have three tiers or levels of protectionto target three buying segments with an ability to expand to additionaltarget consumer groups. A buying segment identifier may allow for activemonitoring and adaptation and the flexible structure may reduce costbarriers to in-market test and learn, adaptation, and expansion.Evolution leveraging this flexibility may support Point Of Sale (“POS”)customization provide a differentiated experience for consumers. Speedto market may be improved as a result of a limited need for programmingand/or filing. Moreover, customization at the POS may provide relativelyfast and accurate offerings in terms of pricing for the consumer orbusiness customer.

Note that the system 100 of FIG. 1 is provided only as an example, andembodiments may be associated with additional elements or components.According to some embodiments, the elements of the system 100automatically transmit information associated with an interactive userinterface display over a distributed communication network. FIG. 2illustrates a method 200 that might be performed by some or all of theelements of the system 100 described with respect to FIG. 1 , or anyother system, according to some embodiments of the present invention.The flow charts described herein do not imply a fixed order to thesteps, and embodiments of the present invention may be practiced in anyorder that is practicable. Note that any of the methods described hereinmay be performed by hardware, software, or any combination of theseapproaches. For example, a computer-readable storage medium may storethereon instructions that when executed by a machine result inperformance according to any of the embodiments described herein.

At S210, a back-end application computer server may access a riskrelationship package data store that contains electronic records, eachelectronic record representing a risk relationship package between anenterprise and an entity (e.g., a homeowner), and including, for eachrisk relationship package, an electronic record identifier and anoverall attribute value. At S220, the back-end application computerserver may transmit to a remote device, associated with an entity, a setof potential types of risk coverage based on information in an availabletype of risk coverage data store. The set of potential types of riskcoverage might include, for example, a fire department service charge,lock replacement, water sewer backup, equipment breakdown, roof damage,weather damage, property damage, personal injury, etc.

At S230, the system may receive, from the remote device, an indicationof a selected subset of the potential types of risk coverage. Based onthe received indication and a pre-determined rule, at S240 the systemmay generate a risk relationship package for the entity using a flexiblestructure framework (e.g., as described in connection with FIGS. 4through 12 ). The risk relationship package may include, in someembodiments, pre-grouped types of risk coverage in addition to theselected subset of the potential types of risk coverage received fromthe user device. The pre-grouped types of risk coverage may be, forexample, associated with at least three coverage tiers. In this case,the back-end application computer server might automatically suggest oneof the coverage tiers for the entity (e.g., as being most appropriatefor the entity). The automatic suggestion of one of the coverage tiersmight be based on, at least in part, answers provided by the entity to aseries of questions.

At S250, an overall attribute value may be calculated for the generatedrisk relationship package based on an attribute algorithm such that atleast one reduction to the overall attribute value is applied based onan amount associated with the selected subset (e.g., a volume premiumdiscount in accordance with any of the techniques described with respectto FIG. 8 ). The attribute algorithm might apply, for example: a flatpackage discount; a package volume discount; a package volume discountwith an eligibility component; a package discount at coverage level;etc. At S260, a new electronic record may be created in the riskrelationship package data store, including the calculated overallattribute value. In some embodiments, the generated risk relationshippackage is associated with a homeowner's insurance policy and thecalculated overall attribute value is an insurance premium value.

In this way, embodiments may deliver newly configured packages, enablingconsumers to select an optional bundle that meets their needs within astructure that supports ongoing evolution of the offering to optimizeimpact. Note that such insurance packages might be provided for consumerproducts and/or business insurance products. The coverage packages maybe organized around impactful, popular coverages based on consumerresearch and be offered at three price points to meet the needs of arange of insureds. All coverages in coverage packages might also beavailable for purchase as individual endorsements. The package price maythen be discounted from the cost of purchasing the coverages separately.

FIG. 3 is one possible homeowners insurance package evolution 300 inaccordance with some embodiments. In a first phase 310, a flexiblestructure framework and fixed packages may use a package rule and baseendorsements. For example, three package levels might be provided (basedon a number of included optional coverages) and be rated at an optionalcoverage level. Eligible optional coverages may be provided withstand-alone and/or package rates for each package level. The informationmay be presented to consumers in a side-by-side display showing thethree packages on a quote premium screen. The price displayed mightrepresent an incremental cost, total quote premium including thepackage, etc.

In a second phase 320, thematic compositions and targeting may beprovided with the introduction of additional version codes and packagerates may be adjusted based on experience and leanings. A side-by-sidedisplay may be provided based on consumer targeting and the system mightautomatically highlight a targeted package. Additional defined packageofferings with thematic composition may be added to the three originallevels to target consumers based on buying segment and themeidentifiers.

In a third phase 330, limited dynamic assembly may be provided with theintroduction of dynamic version code assignments. Package rates may beadjusted based on experience and leanings and be presented side-by-sidewith the dynamically assembled package being shown first. The system maydisplay a buying segment target package second and a thematic targetpackage third. In some embodiments, the number of packages forside-by-side display may be reduced and optional coverage inclusions maybe based on insured/property characteristics, quote flow questions, etc.

In a fourth phase 340, POS customization may be provided with theintroduction of a custom package level, version codes, and rules. Adirect custom selection screen and agency preference selection screenmay provide a side-by-side display on quote premium screen of custompackage and one other targeted package. The composition may be basedupon custom selections of quote or agency preferences.

Various coverage selections might be included in consumer research todetermine packages and/or prices. For example, FIG. 4 illustrates 400coverage compositions for homeowners insurance coverage packagesaccording to some embodiments. As shown in FIG. 4 , coverages shown in“bold” typeface represent popular coverages. Three levels may providecustomize protection associated with: price sensitive, value buying, andprotection oriented customers (targeting three buying segments). In someembodiments, unique condominium owner and/or tenant packages may also beprovided.

FIG. 5 illustrates 500 a flexible structure framework for variouspre-defined packages in accordance with some embodiments. In particular,package rules 510, optional coverage rules 520, and a buying segmentidentifier 530 may be provided. The package level may be determinedbased upon the number of coverages within the package. Package rates maybe included in the optional coverage rule 520 and may decrease as thepackage level increases. Versioning may enable varying coverageconfigurations and testing those configurations in the insurance marketover a period of time.

In some embodiments, the system may establish a package base ofcoverages unavailable outside the package to prevent self-selection atPOS. For example, FIG. 6 illustrates package eligible optional or“additional” coverages 600 associated with a flexible structureframework according to some embodiments. These may represent a subset ofoptional coverages and be associated with an expandable portfolio.Moreover, the system may manage package discounting at the coveragelevel provides maximum flexibility for profitability management.

In some embodiments, package foundation endorsements may includecoverages otherwise unavailable. Each base may build on a prior base andprovide a greater number of coverages. For example, FIG. 7 illustratespackage coverage foundation endorsements 700 for three levels inaccordance with some embodiments. Note that package foundationendorsements may provide additional margin and/or avoid system designcomplexity associated with optional coverage selection in transactions.Package foundation endorsements may also mitigate against adverseselection via unmanaged self-selection at POS and/or eliminate expensesassociated with creating, pricing, and programming additional newendorsements.

Package premiums may be calculated by summing individual premiums foreach included coverage. Premiums may vary by package level with embeddeddiscounting based on the number of eligible coverages and coverage type.This approach may provide an enterprise with pricing flexibility whilereducing programming requirements. FIG. 8 shows some structure options800 according to some embodiments. Option 1 sums the premiums associatedwith the individual coverages and applies a flat package discount:

(Cov 1+Cov 2+Cov 3)*(Flat Package Discount)

Such an approach may make it easy to understand the bundle discount andto modify coverages within a package. However, this option may notprovide an ability to vary discount by coverage component or to varydiscount by number of coverages.

Option 2 sums the premiums associated with the individual coverages andapplies a discount that varies based on the package:

(Cov 1+Cov 2+Cov 3)*(Package A Discount Level)

This approach may also make it easy to understand the bundle discountand to modify coverages within a package. It may also provide an abilityto vary the discount by package. However, it still might not provide anability to vary the discount by coverage component.

Option 3 applies the package discount, which varies by the number ofeligible coverages, to each eligible coverage. It sums these premiumsand add the premiums for coverages that are ineligible for the discount:

(Cov 1+Cov 2)*(2 Eligible Coverage Discount Level)+Cov 3

Again, this approach makes it easy to understand the bundle discount andto modify coverages w/in a package. This structure for a variablepackage discount provides greater flexibility (but there is still noability to vary discount by coverage component).

Option 4 sums the premiums associated with the individual coverages,each of which vary based on whether the coverages were purchasedstandalone or via a package. The coverage package rate varies bypackage:

(Cov 1 Pkg A Rate+Cov 2 Pkg A Rate+Cov 3 Pkg A Rate)

With this approach, premiums are captured at the coverage level andthere is an ability to vary the discount and price at the coverage levelproviding optimal pricing flexibility. It may also provide an ability tovary the discount by package.

According to some embodiments, the system may assign an appropriatepackage code to each quote/policy. This code may be used to attach formsand apply package pricing for coverages included in the selectedpackage. Rate tables for all package eligible coverages may includepackage pricing to increase speed to market as package compositions aremodified over time. For example, FIG. 9 is a structure design 900 inaccordance with some embodiments. The design 900 includes a water sewerbackup table 910, identify fraud table 920, and trust 930 associatedwith a rate engine along with a reference table 940.

In some embodiments, the system may assign a package level code based onthe selected package. This code (e.g., “P1”) may then be used as part ofthe key to determine the appropriate rate. Structuring rate tables bypackage level for a subset of coverages (and not as part of one of thepre-defined packages) may increase speed to market if/when thecomposition of the packages is changed (pending DOI approval of therates and package rules). The reference table 940 may define each of thecoverages within the various packages and dictate which coverages willbe displayed when the packages are presented to a consumer. Thereference table 940 may also ensure that customers who select a packagewill not receive a package discount on coverages that are not currentlyoffered via the packages.

Insurance packages might not have a static form, but instead utilize a“flexible structure framework” associated with individually availableoptional coverages. This may enable modifications to coverageconfigurations over time to optimize take rate, profitability, etc. Forexample, FIG. 10 illustrates a version and filing approach 1000 for aprice sensitive package 1010, a value buyer package 1020, and aprotection seeker package 1030 (with three different price pointsdiscounted as compared to individually purchased insurance to targetthree customer buying segments). Optional coverage endorsements 1050 mayalso be provided to be available individually and pre-set bundles may beincluded in option packages. Selected endorsements 1050 may be broughtinto the appropriate package 1010, 1020, 1030 and “shrink wrapped” to bedelivered as an insurance package for a homeowner. According to someembodiments, individual coverage endorsements may be filed with a DOIalong with a pricing table (e.g., $X as a standalone, $Y as part of aprice sensitive package, etc.).

Defining packages based upon number of coverages pulled from a definedpool of eligible options may provide flexibility to change coveragecomposition with minimal filing and programming. This can create anin-market testing capability resulting in different package compositionsby state or over time. Neighbors purchasing the same level package mayhave different coverages within it. Version codes may be utilized toidentify varying compositions within the same volume-based package level(letting an enterprise monitor the different coverage compositions).

Some embodiments may support the development of additional packagestargeting buyers from a perspective that is intuitive to consumers andresonates emotionally with how they identify their priorities orlifestyles. For example, FIG. 11 shows coverage configuration versions1100 associated with a suburban home protection package, digitaldenizens, outdoorsy family, etc. Embodiments may support a degree of POScustomization by letting consumers select their own coverage options forinclusion in an individualized package. Consumers may select aprice-point and be provided a choice of a specified number of optionsfrom designated available coverages at set limit levels.

An initial filing may avoid defining packages coverage compositions tomaximize an enterprise's ability to quickly implement changes as itmonitors package take rate and profitability. Some state DOI may requiremore details, a filing strategy may include options to preserve as muchflexibility and speed to market capability as possible. For example,FIG. 12 is a filing approach 1200 for coverage packages according tosome embodiments. Option 1 uses file rates and rules that provide forthe most flexibility to modify package composition as the enterprisestests and learns. No specific coverages compositions might be listed inthe rule and all packages may include a package base which is onlyavailable in a package. In addition to the package base, other eligiblecoverages may be included in the packages. In some embodiments, apackage level is determined based on the number of eligible coverages inthe package. The minimum number of optional coverages required toconstitute the various package levels may be specified, and rates may bediscounted based on the package level (e.g., the number of coverages)and/or coverage type

Option 2 may file package eligible options to provide some flexibilityas we modify package composition. In this case, eligible coverages maybe listed in the rule. Option 3 may file pre-defined packagecompositions and the corresponding rates. In this case, coveragecompositions may be defined in the rule. Moreover, a fall back may beprovided to file coverages with package level rates only for thosecoverages included in the pre-defined packages.

FIG. 13 is a package creation method 1300 in accordance with someembodiments. At 51310, the system may transmit a set of potential typesof insurance coverages based on information stored in an available typeof insurance coverage data store (e.g., by transmitting the informationto a homeowner). The system may then receive an indication of selectedsubset of the potential types of insurance coverage at S1320 and, basedon the received indication and pre-determined rule, generate aninsurance package for the homeowner using a flexible structure frameworkat S1330. At S1340, the system may automatically calculate an overallpremium for the generated insurance package based on an attributealgorithm such that at least one reduction to the overall attributevalue is applied based on an amount associated with the selected subset.

FIG. 14 is method 1400 associated with protection tiers or levelsaccording to some embodiments. At S1410, the system may provide threelevels of pre-defined insurance packages to a homeowner (e.g.,representing coverages that are popular with consumers). The system maythen receive from the homeowner a selection of one of those levels atS1420. The system may also receive indications of optional additionalcoverages from the homeowner at S1430 and automatically generate a riskrelationship package for the homeowner at S1440 using a flexiblestructure framework. The system may then calculate an overall insurancepremium for the newly generated insurance package at S1450.

FIG. 15 is a more detailed block diagram of a system 1500 according tosome embodiments. Here, a back-end application computer server 1550 usesa flexible structure engine 1555 (e.g., associated with ArtificialIntelligence (“AI”), Machine Learning (“ML”), or a predictive model) toanalyze information in an insurance policy package database 1510. Theinsurance policy package database 1510 may contain, for example,electronic data records 1512 containing an insurance policy packageidentifier 1514, selected insurance coverages 1516, insurance premiumvalues 1518, etc. The flexible structure engine 1555 may also receiveinformation from an available coverages database 1520 (e.g., associatedwith different types of risks), customer profile data 1530, third-partydata 1532, and historical data 1534. Moreover, the back-end applicationcomputer server 1550 may exchange information (e.g., via a firewall1565) with multiple remote user devices 1560, 1570 (e.g., such as thoseassociated with customers, homeowners, agents, administrators, etc.).

In some embodiments, the customer profile data 1530 may be used toidentify a persona profile that describes a homeowner (and that personamight be used to suggest an appropriate package level, optionalcoverages that might be of interest, etc.). FIG. 16 illustrates aquestions display 1600 that may be used to code respondents intopreliminary persona categories in accordance with some embodiments. Thequestions display 1600 might include an interactive user interface area1610 that the homeowner can use (e.g., via a touchscreen or computermouse pointer 1690) to select answers to various questions. Selection ofa “Submit” icon 1620 may cause those answers to be transmitted to theenterprise.

The embodiments described herein may be implemented using any number ofdifferent hardware configurations. For example, FIG. 17 illustrates anapparatus 1700 that may be, for example, associated with the systems100, 1500 described with respect to FIGS. 1 and 15 , respectively. Theapparatus 1700 comprises a processor 1710, such as one or morecommercially available Central Processing Units (“CPUs”) in the form ofone-chip microprocessors, coupled to a communication device 1720configured to communicate via a communication network (not shown in FIG.17 ). The communication device 1720 may be used to communicate, forexample, with one or more remote third-party information suppliers,administrator computers, and or communication devices (e.g., PCs andsmartphones). Note that communications exchanged via the communicationdevice 1720 may utilize security features, such as those between apublic internet user and an internal network of an insurance companyand/or an enterprise. The security features might be associated with,for example, web servers, firewalls, and/or PCI infrastructure. Theapparatus 1700 further includes an input device 1740 (e.g., a mouseand/or keyboard to enter information about package options, thirdparties, etc.) and an output device 1750 (e.g., to output reportsregarding packages, recommended changes, etc.).

The processor 1710 also communicates with a storage device 1730. Thestorage device 1730 may comprise any appropriate information storagedevice, including combinations of magnetic storage devices (e.g., a harddisk drive), optical storage devices, mobile telephones, and/orsemiconductor memory devices. The storage device 1730 stores a program1715 and/or insurance package tool or application for controlling theprocessor 1710. The processor 1710 performs instructions of the program1715, and thereby operates in accordance with any of the embodimentsdescribed herein. For example, the processor 1710 may transmit, to aremote device associated with an entity (e.g., a homeowner), a set ofpotential types of risk coverage based on information in an availabletype of risk coverage data store. The processor 1710 may then receive anindication of a selected subset of the potential types of risk coverageand, based on the received indication and a pre-determined rule,generate a risk relationship package for the entity using a flexiblestructure framework. The processor 1710 may calculate an overallattribute value for the package based on an attribute algorithm (suchthat at least one reduction to the overall attribute value is appliedbased on an amount associated with the selected subset) and create a newelectronic record in the risk relationship package data store, includingthe calculated overall attribute value.

The program 1715 may be stored in a compressed, uncompiled and/orencrypted format. The program 1715 may furthermore include other programelements, such as an operating system, a database management system,and/or device drivers used by the processor 1710 to interface withperipheral devices.

As used herein, information may be “received” by or “transmitted” to,for example: (i) the back-end application computer server 1700 fromanother device; or (ii) a software application or module within theback-end application computer server 1700 from another softwareapplication, module, or any other source.

In some embodiments (such as shown in FIG. 17 ), the storage device 1730further stores a risk relationship package database 1800, a third-partydata source 1760 (e.g., associated with someone other than the insuredand the insurer), historical data 1770 (e.g., past answers fromhomeowners and what packages they ended up selecting), and a homeownerprofile 1780. An example of a database that might be used in connectionwith the apparatus 1700 will now be described in detail with respect toFIG. 18 . Note that the database described herein is only an example,and additional and/or different information may be stored therein.Moreover, various databases might be split or combined in accordancewith any of the embodiments described herein. For example, the riskrelationship package database 1800 and third-party data source 1760might be combined and/or linked to each other within the program 1715.

Referring to FIG. 18 , a table is shown that represents the riskrelationship package database 1800 that may be stored at the apparatus1800 according to some embodiments. The table may include, for example,entries associated with insurance policy packages that have beengenerated by an enterprise using a flexible structure framework. Thetable may also define fields 1802, 1804, 1806, 1808, 1810 for each ofthe entries. The fields 1802, 1804, 1806, 1808, 1810 may, according tosome embodiments, specify: a homeowner identifier 1802, a policyidentifier 1804, a persona 1806, optional coverages 1808, and an overallpremium 1810. The risk relationship package database 1800 may be createdand updated, for example, based on information electrically receivedfrom various computer systems, including those associated withhomeowners.

The homeowner identifier 1802 may be, for example, a unique alphanumericcode identifying a customer (or potential customer) of an insuranceprovider. The policy identifier 1804 may identify an existing insurancepolicy or package (or potential new insurance policy or package that isbeing generated for the customer). The persona 1806 may describe thecustomer based on answers to questions, demographic information, etc.and may provide some indication as to a protection level or optionalcoverages that might be appropriate for the customer. The optionalcoverages 1808 may comprise identifiers indicating potential insurancecoverages for the customer or coverages that have been actually selectedby the customer. The overall premium 1810 might be a calculated valuefor the policy identifier 1804 based on any of the algorithms orcalculations described herein (e.g., as described in connection withFIG. 8 ).

Thus, embodiments may provide systems and methods to automaticallyestablish a risk relationship package using a flexible structureframework in a way that provides fast and accurate results. Embodimentsmay also provide an ability to access and interpret data in a holistic,tactical fashion. According to some embodiments, the system may beagnostic regarding particular web browsers, sources of information, etc.For example, information from multiple sources (e.g., an internalinsurance policy database and an external data store) might be blendedand combined (with respect to reading and/or writing operations) so asto appear as a single “pool” of information to a user at a remotedevice. Moreover, embodiments may be implemented with a modular,flexible approach such that deployment of a new system for an enterprisemight be possible relatively quickly.

The following illustrates various additional embodiments of theinvention. These do not constitute a definition of all possibleembodiments, and those skilled in the art will understand that thepresent invention is applicable to many other embodiments. Further,although the following embodiments are briefly described for clarity,those skilled in the art will understand how to make any changes, ifnecessary, to the above-described apparatus and methods to accommodatethese and other embodiments and applications.

Although specific hardware and data configurations have been describedherein, note that any number of other configurations may be provided inaccordance with embodiments of the present invention (e.g., some of theinformation associated with the displays described herein might beimplemented as a virtual or augmented reality display and/or thedatabases described herein may be combined or stored in externalsystems). Moreover, although embodiments have been described withrespect to particular types of insurance policies, embodiments mayinstead be associated with other types of insurance policies in additionto and/or instead of the policies described herein (e.g., businessinsurance policies, automobile insurance policies, etc.). Similarly,although certain attributes were described in connection with someembodiments herein, other types of attributes might be used instead.Still further, the displays and devices illustrated herein are onlyprovided as examples, and embodiments may be associated with any othertypes of user interfaces. For example, FIG. 19 illustrates a handheldtablet computer 1900 showing an insurance package display 1910 accordingto some embodiments. The insurance package display 1910 might includeuser-selectable data that can be selected and/or modified by a user ofthe handheld computer 1900 (e.g., via an “Update” icon 1920) to viewupdated insurance information associated with an entity and/orenterprise (e.g., including, in some embodiments, an overall insurancepremium value).

The present invention has been described in terms of several embodimentssolely for the purpose of illustration. Persons skilled in the art willrecognize from this description that the invention is not limited to theembodiments described but may be practiced with modifications andalterations limited only by the spirit and scope of the appended claims.

What is claimed:
 1. A risk relationship package creation system implemented via a back-end application computer server, comprising: (a) a risk relationship package data store associated with an encrypted database management system that contains electronic records, each electronic record representing a risk relationship package between an enterprise and an entity, and including, for each risk relationship package, an electronic record identifier and an overall attribute value; (b) an available type of risk coverage data store associated with the enterprise; (c) the back-end application computer server, coupled to the risk relationship package data store and the available type of risk coverage data store, including: a computer processor, and a computer memory, coupled to the computer processor, storing instructions that, when executed by the computer processor, cause the back-end application computer server to: (i) transmit, to a remote device associated with the entity, a set of tiers for a type of risk coverage based on information in the available type of risk coverage data store, (ii) receive, from the remote device, an indication of a selected tier of the set of tiers, (iii) based on the received indication, generate a risk relationship package for the entity using a flexible structure framework, (iv) calculate an overall attribute value for the generated risk relationship package based on an attribute algorithm, and (v) create a new electronic record in the risk relationship package data store, including the calculated overall attribute value; and (d) a communication port coupled to the back-end application computer server to facilitate a transmission of data to the remote device to support an interactive display, including an indication of the calculated overall attribute value, via a distributed communication network.
 2. The system of claim 1, wherein the generated risk relationship package includes a selected additional risk coverage in addition to the selected tier of the set of tiers received from the remote device.
 3. The system of claim 2, wherein the set of tiers comprises at least three coverage tiers.
 4. The system of claim 3, wherein the back-end application computer server automatically suggests one of the coverage tiers for the entity.
 5. The system of claim 4, wherein said automatic suggestion of one of the coverage tiers is based at least in part answers provided by the entity to a series of questions.
 6. The system of claim 1, wherein the generated risk relationship package is associated with a homeowner's insurance policy.
 7. The system of claim 6, wherein the calculated overall attribute value is an insurance premium value.
 8. The system of claim 7, wherein the set of risk coverage tiers include at least one of: (i) a fire department service charge, (ii) lock replacement, (iii) water sewer backup, (iv) equipment breakdown, (v) roof damage, (vi) weather damage, (vii) property damage, and (viii) personal injury.
 9. The system of claim 7, wherein the attribute algorithm applies at least one of: (i) a flat package discount, (ii) a package volume discount, (iii) a package volume discount with an eligibility component, and (iv) a package discount at coverage level.
 10. A computerized risk relationship package creation method implemented via a back-end application computer server, comprising: accessing, by the back-end application computer server, a risk relationship package data store associated with an encrypted database management system and that contains electronic records, each electronic record representing a risk relationship package between an enterprise and an entity, and including, for each risk relationship package, an electronic record identifier and an overall attribute value; transmitting, from a computer processor of the back-end application computer server to a remote device associated with the entity, a set of tiers for a type of risk coverage based on information in an available type of risk coverage data store; receiving, from the remote device, an indication of a selected tier of the set of tiers; based on the received indication, generating a risk relationship package for the entity using a flexible structure framework; calculating an overall attribute value for the generated risk relationship package based on an attribute algorithm; and creating a new electronic record in the risk relationship package data store, including the calculated overall attribute value.
 11. The method of claim 10, wherein the generated risk relationship package includes a selected additional risk coverage in addition to the selected tier of the set of tiers received from the remote device.
 12. The method of claim 11, wherein the set of tiers comprises at least three coverage tiers.
 13. The method of claim 12, wherein the back-end application computer server automatically suggests one of the coverage tiers for the entity.
 14. The method of claim 13, wherein said automatic suggestion of one of the coverage tiers is based at least in part answers provided by the entity to a series of questions.
 15. A non-transitory, computer-readable medium storing instructions, that, when executed by a processor, cause the processor to perform a risk relationship package creation method implemented via a back-end application computer server, the method comprising: accessing, by the back-end application computer server, a risk relationship package data store with an encrypted database management system and that contains electronic records, each electronic record representing a risk relationship package between an enterprise and an entity, and including, for each risk relationship package, an electronic record identifier and an overall attribute value; transmitting, from the back-end application computer server to a remote device associated with the entity, a set of tiers for a type of risk coverage based on information in an available type of risk coverage data store; receiving, from the remote device, an indication of a selected tier of the set of tiers; based on the received indication, generating a risk relationship package for the entity using a flexible structure framework; calculating an overall attribute value for the generated risk relationship package based on an attribute algorithm; and creating a new electronic record in the risk relationship package data store, including the calculated overall attribute value.
 16. The medium of claim 15, wherein the generated risk relationship package is associated with a homeowner's insurance policy.
 17. The medium of claim 16, wherein the calculated overall attribute value is an insurance premium value.
 18. The medium of claim 17, wherein the set of risk coverage tiers include at least one of: (i) a fire department service charge, (ii) lock replacement, (iii) water sewer backup, (iv) equipment breakdown, (v) roof damage, (vi) weather damage, (vii) property damage, and (viii) personal injury.
 19. The medium of claim 17, wherein the attribute algorithm applies at least one of: (i) a flat package discount, (ii) a package volume discount, (iii) a package volume discount with an eligibility component, and (iv) a package discount at coverage level. 